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ABSTRACT 


This thesis investigated the current infrastructure for web-based simulations 
using the DIS network protocol. The main technologies studied were 
WebSockets, WebRTC and WebGL. This thesis sought readily available means 
to establish networks for interchanging DIS message (PDUs), so the WebSocket 
gateway server from Open-DIS project was used to construct a Client-Server 
structure and PeerJS API was used to construct a peer-to-peer structure. WebGL 
was used to create a scene and render 3D models in browsers. A first-person- 
shooter tank game was used as a test application with both WebSocket and 
WebRTC infrastructures. 


Experiments in this thesis included measuring the rate of sending and 
receiving DIS packets and analysis of the tank game by profiling tools. All the 


experiments were run on Chrome and Firefox browsers in a closed network. 


The experimental results showed that both WebSocket and WebRTC 
infrastructures were competent enough to support web-based DIS simulation. 
The results also found the significant differences of performance between 
Chrome and Firefox. Currently, the best performance is provided by the 
combination of Firefox using the WebRTC framework. The analysis of the tank 
game showed that most of the browser’s computational resources were spent on 
the WebGL graphics, with only a small percentage of the resources expended on 


exchanging DIS packets. 
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I. INTRODUCTION 


In the military domain, simulation is widely used for training, education, 
and analysis. Many simulation systems have been developed to support different 
missions, such as flight simulators for training and educating pilots, or Virtual 
Battlespace 2 (VBS2) for educating platoon leaders. After multiple simulation 
systems have been established, users may want to integrate them for joint 
training purposes. Therefore, the requirement for interoperability among systems 


becomes an important topic. 


In the 1990s, the Simulation Interoperability Standard Organization (SISO) 
reached an agreement on a distributed interactive simulation (DIS) protocol. 
SISO also had the DIS protocol ratified as an IEEE standard, so it is now 
available for anyone to read and implement. Currently, the DIS protocol has been 
used to develop many simulation systems or communicate among existing 
systems by formatting the exchanged data. There are many existing simulation 
systems that have implemented the DIS protocol by different programming 
language (Rogerson, 1997; McGregor, Brutzman & Grant, 2008). One purpose of 
military simulation is to construct a live, virtual and constructive (LVC) 
environment for military training, education, and analysis (Farlane et al., 2004). 
“Live” refer to real people operating real systems such as real pilots flying F-16 
fighters. “Virtual” refers to real people operating simulated systems, such as real 
drivers in high-occupancy vehicle (HOV) simulators. “Constructive” describes a 
simulation in which both people and systems are simulated such, as a simulated 


opponent force—an opponent fighter with Al—in a simulated system. In order to 


achieve LVC architecture, simulation systems have to exchange information with 
each other, and DIS_ protocol represents a_ standardized format for 


communicating data. 


With the developments of web technology and the improvements of 
computer performance, more and more applications can be run in web browsers. 


This thesis implemented several web technologies that mainly included 
1 


WebSocket, WebRTC, and WebGL to discuss the feasibility of applying DIS 
protocol to multiple-user web-based simulation. The client/server and peer-to- 
peer architectures can be used to develop web-based simulations, and their 
respective technologies are WebSocket and WebRTC. This thesis compared the 
performance of sending and receiving DIS messages in these two different 
networking architectures, and incorporated WebGL components to develop a 


first-person-shooter game to analyze the performance in different browsers. 


This thesis also discussed the advantages of web-based simulation. The 
features of web-based simulation are easier to upgrade (centralized content), are 
cross-platform, and are widely accessible via computers, tablets, and mobile 
devices. For example, when people want to execute simulation systems, they 
have to set up an environment for execution. This environment includes a 
physical desktop setup, an operating system install, a simulation software install, 
and a peripheral device setup. Typically, computers have pre-installed operating 
systems with peripheral device setups. The simulation system, however, has to 
be installed additionally, and each one has its own compatible operating system 
(e.g., Windows 7, Windows Server 2012, UNIX, and different versions of Linux). 
When users want to run a specific simulation system on computers, they have to 
check and configure all operating systems and system setups before running the 
simulation. The computer preparation for running this specific simulation system 


may be a tedious and inefficient process. 


Web-based simulation can relieve the above situation and increase the 
efficiency of system readiness. Nowadays, the major browsers that most people 
use on desktop and laptop computer are Chrome, Firefox, Internet Explorer, and 
Safari. All the experiments, comparisons and analysis in this thesis, however, 
were run in Chrome and Firefox because both Chrome and Firefox support the 
same web technologies. In addition, both Chrome and Firefox provide installers 
for mainstream operating systems such as Windows, Mac OS, and Linux, so 
web-based simulation can run on almost every operating system through these 


two platforms (Chrome and Firefox). 


The thesis begins by describing the motivation and the benefits of 
browser-based simulation and outlining the technologies for constructing the 
infrastructures. Next, the thesis describes design and implementation for testing 
the performance among several variables. The latencies and the results were 


discussed at the end with commentary for future work. 
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ll. BACKGROUND 


In the past, developing a networked and interactive simulation system 
usually required complex programming skill. Many programming language and 
technologies have been developed to reduce the complexity of programming. 
The following sections describe motivations and several present technologies for 


developing a small-scale and interactive simulation. 


A. MOTIVATION 


With the prosperity of the Internet, more and more web applications have 
been developed. With the development of web technologies and the increasing 
of computational power, the possibility of developing interactive and complicated 
applications in web is promising, and because of the elements of interaction and 
logical computation capability, web-based simulation systems are more 
achievable. Web-based simulation is exploiting resources and technologies 
offered by the World Wide Web (WWW) to represent traditional simulation 
systems (Fishwick, 1996). In other words, web-based simulation uses web 
browsers as graphical interfaces to link users and simulation systems. The 
benefits of exploiting web-based simulation are cross-platform, collaboration, 
model reusing, deployment, wide availability, versioning control, etc. Modern 
browser companies provide browser installers for different operating systems, 
and most modern browsers support the same web technologies (e.g., JavaScript, 
JSON, binary data format, WebGL, and WebSocket), which increases the cross- 
platform capability. Collaboration is useful in that web simulations can be 
designed to help people involved in a common task to accomplish goals. Model 
reusing is that many existing 3D graphic formats such as .dae, .obj, .blend can 
be imported into web applications, so software engineers can focus on the 
design of web applications rather than making 3D models. Web applications also 
increase their accessibility and deployment to users because every operating 


system has its compatible browsers that support the same web technologies. On 
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server side, web applications can ease the burden of versioning control for 
system managers. They only need to update archives on server and ask users to 
reload and refresh web contents. Additionally, web applications are easy to 
execute because browsers do not need further configuration or plug-in to run 
applications. For the military domain, state-of-the-art web technologies can not 
only construct web-based simulations (McGregor & Brutzman, n.d.), but also 
enable communication between web applications such as Google Maps and 
existing simulation systems such as VBS2, OneSAF, and JCATS via proper 
gateways(McGregor, Blais, & Brutzman, n.d.). The ability of interoperating with 
other systems increases the practicability of web-based simulation. Furthermore, 
inventors of web technologies also ease the learning curve of developing web 
applications. HTML5 and JavaScript are easy to learn and practice programming 
languages, and developers do not require compilation JavaScript manually or 


extra procedures for users to run web applications. 


B. TECHNOLOGIES 


In order to establish a web-based simulation with the abilities of easy 
deployment and maintenance, many elements have to be applied. These include 
networking architecture, DIS protocol, JavaScript, web server with WebSocket, 
Web Real-Time Communication (WebRTC), WebGL, JSON format DIS, and 


binary format DIS messages. 


1. Networking 


Networking is separated into five layers: application, transport, network, 
link, and physical. Most of the applications are implemented in the application 
layer over TCP/IP protocol, a framework for communication between devices. 
TCP/IP is a software concept that allows one machine to send bytes to another, 
without Knowing the content or meaning of those sent bytes. Applications are 
used to interpret TCP/IP sending data. Modeling and simulation (M&S) 
networking protocols are standardized in the application layer, and all the M&S 
applications such as JCATS and OneSAF relay on this layer, too. 
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Network architecture usually contains more than two hosts (Steed & 
Oliceira, 2010, Ch. 4) in military simulations, so it is important to define models 
for multi-host connections: simple peer-to-peer, peer-to-peer with master host, 
peer-to-peer with rendezvous server, and client/server. Simple peer-to-peer 
communication means that each host has a configuration file to record necessary 
information of all the participants (as well as address/port data) and then sends 
updates to all the other hosts within the network group. Peer-to-peer with master 
means that one the participants will be the rendezvous access point. The 
rendezvous point has a well-known IP and port number, so any host who wants 
to join the network can obtain other participant information from the master. The 
advantage over the simple peer-to-peer model is that there is no need to collect 
every participant's IP address, port number and other information beforehand. 
The peer-to-peer with rendezvous server model uses a server that has 
information for all participants. Every host who wants to join the network has to 
connect to the rendezvous server first to ask for network environment 
information. The difference between peer-to-peer with master and peer-to-peer 
with rendezvous server is that the master is one of the network participants but 
the rendezvous server, who is not a participant in the network, is only the 
distributor with all the hosts’ information for a new host who wants to join the 
network. Client-server architecture means that each host connects to the server, 


and the server is responsible for every communication between hosts. 


2. DIS Protocol 


DIS is a standardized protocol used to communicate and exchange 
information in a multiplayer simulation system (D/S /EEE Std 1278.1-2012- 
Standard for Distributed Interactive Simulation—Application Protocols, 2012). It 
also allows two or more different types of simulators to interact or interoperate, 
especially those simulators that have human-in-the-loop elements. For example, 
a joint forces exercise uses ship simulators and flight simulators to train the 
capability of cooperation. The method that DIS uses to interchange information is 


based on protocol data unit (PDU) messages; there are many kinds of PDUs, 
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such as entity state PDU (ESPDU), detonation PDU and entity damage status 
PDU. Different PDUs have different lengths and fields to contain the variety of 
information, so simulation system can communicate with each other by sending 
and receiving PDUs. Although there are many kinds of PDUs with different fields 
for restoring information, every PDU starts with the same header that is used to 
differentiate PDU types when receiving DIS packets. Appendix A displays a table 
containing entity state PDU fields, and shows that the common PDU header used 
the first 96 bits. The table also shows the other fields of ESPDU. ESPDU is the 
most frequent PDU in DIS simulation, and it is used for interchanging the 
information of entity’s state. The information includes entity ID, entity type, 
location and orientation in the simulated world, entity appearance, entity 


capabilities, etc. 


The DIS uses a heartbeat strategy, in which entities periodically send out 
their PDUs even if they do not change their properties or states. A critical issue, 


however, is the rate at which each entity sends its PDUs—sending data too often 


would cause networking congestion, latency or losing data, etc. In a large-scale 
scenario, some of the entities are relatively slow or even in a Static state (e.g., 
tanks or infantry), but some of the entities move quickly (e.g., airplanes). 
Therefore, the developer has to set different update rates for different kinds of 
entities to avoid redundant DIS packets transferring in network. Another principle 
is not to let the late-joining hosts wait too long for those slow-moving entities. DIS 
simulation is mainly used in military domains, and it usually assumes that DIS 
simulation is implemented in a high-performance intranet with high security, one 
in which participants will not send fake or swindling messages. Additionally, in 
order to simplify data transfer, DIS usually broadcasts or multicasts its PDUs 
based on UDP socket. 


3. JavaScript 


JavaScript is the scripting language of the web, and all modern web 


browsers support JavaScript (w3schools, n.d.). JavaScript lets browsers have the 
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capability of logical computation and client-side scripting that let users change or 
interact with web content depending on user input, which is in contrast with 
server-side scripts such as PHP, Java and Python (Flanagan, 2011; Powers, 
2010). 


4. Web Server with WebSockets 


Traditional web servers only talks to a user's page once, when user loads 
the content from the web server; this is because the web pages were designed to 
be static originally. This causes a problem for web pages that need highly 
interaction with users. With WebSocket, JavaScript opens a TCP socket to 
establish a communication channel to the server and request this special type of 
TCP socket to be opened for delivering arbitrary application protocols between 
client and server (Grigorik, 2013, Ch. 17). This specialized TCP socket can 
remain open, so web pages can keep updating its contents periodically with 
some JavaScript program. Furthermore, WebSocket also has features of low 
latency compared to HTTP polling; and higher bandwidth. WebSocket makes 


possible to run interactive and real-time applications in web browsers. 


5. WebRTC 
WebRTC—whose API is defined by W3C and protocol is defined by 


lIETF—is a plugin-free real-time communication API that is used for high-quality 
audio, video and data communication with low cost (“WebRTC,’ n.d.). The 
features of WebRTC are binding a UDP socket, peer-to-peer connection, and 
cross-platforms interaction. Four main tasks for WebRTC are acquiring audio and 
video, establishing a connection between peers, communication audio and video, 
and communicating arbitrary data. In order to achieve the above tasks, three 
main JavaScript APls—MediaStreams (a.k.a. getUserMedia), 
RTCPeerConnection and RTCDataChannel are applied. So far, WebRTC can 


run in Chrome, Firefox, and Opera. 


MediaStreams, acquiring audio and video, represents a stream of 


synchronized media, and it can contain multiple audio and video tracks. To 
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obtain a § MediaStream, JavaScript provides a method - called 
navigator.getUserMedia(). When invoking navigator.getUserMedia(), a web 
browser will pop out a HTTPS prompt and ask the user's permission for 
accessing the camera and microphone. While developing web apps. using 
WebRTC API, developers can combine video and audio streams with JavaScript 
Canvas and WebGL. In the mobile devices with multiple cameras or 
microphones, users can choose input devices through WebRTC API. Another 
function of WebRTC is getUserMedia() for capturing user’s screen, which is 


useful for desktop sharing or online remote teaching. 


RTCPeerConnection is implicitly used for audio and video communication 
between peers. A web browser takes the media streams from getUserMedia(), 
plugs them into the peer connection and sends them off to the other side. The 
peer connection is responsible for many things (e.g., signal processing, codec 
handling, peer to peer connection, security, and bandwidth management). 
WebRTC hides most of the complexity from web developers, so developers can 
get media streams easily and plug them into peer _ connection. 
RTCPeerConnection, however, needs servers to broker a connection when the 
peers want to make connections. Therefore, a process called signaling is 
applied, which is like making a telephone call. When a caller makes a phone call, 
the telephone network sends a message to a callee. After the callee answers the 
call, the callee sends a message back to activate a connection. WebRTC does a 
similar thing. When a peer wants to establish a connection, its application first 
signals to the server and then sends session description objects that contain 
parameters and Internet information to the browser for setting up the peer-to- 
peer route. Figure 1 describes the technique of making peer-to-peer connections 
between browsers. WebRTC allows users using any mechanism, protocol, or 
even JSON to make connections to maximize compatibility with established 
technologies, which is defined by JavaScript session establishment protocol 
(JSEP) (Dutton, 2013). 
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Figure 1. JSEP architecture(from Dutton, 2013). 


RTCDataChannel is a_ bidirectional communication of arbitrary data 
between peers, and all the data is encrypted by Datagram Transport Layer 
Security (DTLS), which is a derivative of SSL. RICDataChannel is much like a 
WebSocket, but it relies on the Stream Control Transmission Protocol (SCTP), 
which runs on top of the UDP socket. A comparison of TCP, UDP, and SCTP is 
in Table 1. Based on the features of SCTP, RITCDATAChannel is suitable for 


arbitrary data transfer or multiplayer gaming. 


a 
Reliability reliable Jnreliable configurable 


Transmission byte-oriented nessage-oriented | message-oriented 


Congestion yes 10 yes 
contral 


Table 1. TCP, UDP, and SCTP comparison (from Ristic, 2014). 
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6. WebGL 
Web graphics library (WebGL) is a JavaScript API for rendering 2D or 3D 


graphics in any compatible browser (i.e., most modern browsers such as IE 
v11.0, Opera v23.0, Chrome v36.0, Firefox v31, or Safari v7) (Deveria, n.d.-a). 
WebGL can be used for processing 2D images, creating visually 3D graphics and 
visualizing different kinds of data. For example, D3.js is a JavaScript API that 
visualizes varieties of data in browsers by using HIML, SVG, and CSS. Many 
WebGL libraries are game engines for rendering graphics in browsers; these 
include pixi.js, Phaser, and three.js. WebGL provides the web pages with the 
capability of efficiently creating interactive 2D and 3D graphics to simulate 


objects in web-based simulations. 


1: JSON DIS Format 


JavaScript Object Notation (JSON) is a text-data format that facilitates 
data interchange between different languages (“JSON,” n.d.). The purpose of 
JSON is to store and exchange text information. It is like XML, but smaller, faster, 
and easier to parse. JSON is used to describe data objects not only for 
JavaScript, but also for other programming languages. It is language- 
independent because most of the programming languages have their own 
methods and libraries to parse JSON text. JSON and JavaScript syntactically use 
the same method to describe objects, so when JavaScript receives JSON format 
files, JavaScript uses a built-in eval() function to generate JavaScript objects. 
JSON format is based on two kinds of structure: pairs of name and value, and 
ordered lists. Pairs of name and value is similar to object, record, struct, 
dictionary, hash table, keyed list, or associative array in other languages. 


Ordered list is like array in other languages. 


DIS protocol can be formatted in the form of JSON, which uses a tag- 
value approach to make JavaScript objects containing PDU information. This DIS 
JSON can be sent by WebSocket or WebRTC API after invoking JSON.stringify(), 


a JavaScript method, to convert a JavaScript object to JSON. Another browser 
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can receive this DIS JSON and decode as a JavaScript object. Although JSON 
exchanges data well, it has some inevitable drawbacks. JavaScript object uses a 
tag-value approach, so both publisher and subscriber must have agreement 
regarding field names in the messages. This feature increases the flexibility of 


creating objects, but it uses more bandwidth in messages. 


8. Binary DIS Format 


DIS protocol has been approved by IEEE, and it is widely used in many 
existing simulation applications. Using binary format to exchange messages 
between browsers has a better performance than JSON. Not only the message 
size in DIS binary is smaller than JSON with full DIS messages, but also the 
decoding speed in DIS binary is faster than JSON messages (McGregor et al., 
n.d.). Another advantage of binary DIS format is that DIS is a standardized 
protocol, and using it eliminates the intermediary gateways for protocol 
translation. Additionally, many existing gateways convert different protocols into 
DIS protocol such as JBUS—Joint Simulation Bus—and this increases the 


interoperability between existing simulation systems and web-based simulations. 


Using the above elements—which included networking, DIS protocol, 
programming language, web server with specialized TCP socket, WebRTC, 3D 
graphics, and DIS JSON formatting or binary formatting message—it is possible 


to create an interactive web-based simulation with human-in-the-loop features. 
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ll. EXPERIMENTAL DESIGN 


To understand the performance of running DIS in browsers, this thesis 
created an experimental design with several variables that included networking 
framework (WebSocket and WebRTC), application of WebGL and different 
browsers. The experimental devices included a wired router, two desktop 
computers as clients and one laptop computer as WebSocket server and 
WebRTC server. The specifications of the two desktop computers are as follow: 
Intel® Xeon® CPU E5-1603 0 @ 2.8 GHz, 6 GB memory, NVIDIA Quadro 4000 
graphics card, and Windows 7 64-bit operating system. The specifications of the 
server are as follow: Intel® Core™2 Duo CPU L9400 @ 1.86 GHz, 2 GB memory, 
NVIDIA GeForce 320 M graphics card and Windows 7 32-bit operating system. 


A. NETWORKING FRAMEWORK 


There are many ways to make communication among computers, such as 
client-server architecture or peer-to-peer architecture. Because of the emergence 
of web technologies (WebSocket and WebRTC), many networking architectures 


can be applied to web-based applications. 


1. Client-Server Architecture (WebSocket) 


WebSocket is a TCP-based socket, which means it has all the features of 
TCP socket such as reliable and ordered data interchange, and it can be used to 


transport arbitrary data type for different web applications. 


a. Open-DIS WebSocket Gateway Server 


Open-DIS is an open-source implementation of the DIS protocol in many 
languages (McGregor, Grant, Smith, Harder & Snyder, n.d.). It was developed 
mainly by the Modeling, Virtual Environment, and Simulation (MOVES) Institute 
at the Naval Postgraduate School. From the Open-DIS official website, users 
can download a “javascript.zip” archive to obtain WebSocket gateway server. 
The archive has example applications including sending and receiving native DIS 
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messages and WebSocket/Javascript/WebGL applications. For this experiment, 
the WebSocket application was run in NetBeans, which is a free integrated 
development environment (IDE) for developing desktop, mobile and web 


applications with JAVA, C++, HTML5, JavaScript and more. 


b. Framework 


The DIS implementation of WebSocket gateway server is client-server 
architecture, shown in Figure 2. Every DIS message that is sent from the web 
browser must go through the WebSocket gateway server. The server will repeat 
received DIS messages to all connected web browsers. Because all the client 
browsers are connected to the server, the server plays a vital role in a client- 
server web-based simulation. If the server loses its networking connection, all the 
browsers will lose their ability to interoperate, and then the web-based simulation 


will become a single-player game or crash. 


heed 
a 


VWiebSockel Gateway 





Cent 1 Client 2 Client 3 


Figure 2. WebSocket networking framework. 


2. Peer-to-Peer Architecture (WebRTC) 
Unlike the WebSocket, WebRTC uses UDP sockets that have no flow 


control and no congestion control. They are also unreliable and offer unordered 
data exchange to transfer data. The WebRTC data channel, however, uses 
SsCTP—which is a protocol on top of the UDP sockets—to configure data 
reliability and to order and control data flow and congestion. The networking 


architecture of WebRTC is like a peer-to-peer with rendezvous server model. 
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a. PeerJS 


PeerJS is an application programming interface (API) based on WebRTC 
(Bu & Zhang, n.d.). It wraps WebRTC implementation and provides a fully 
documented and easily configurable API for developers to create peer-to-peer 
connections in web browsers with nothing but a unique ID. Client browser 
creates a unique ID and connects to PeerServer, and the server uses this ID to 
identify and deliver connection information to the prospective peers. The ID Is 
formed with numbers and letters. If a client browser connects to a PeerServer 
without a unique ID, the PeerServer would create an ID for this active client. If a 
client-browser connects to a PeerServer with an ID that has been used for other 
client browser, this client would connect as failed, and the server would respond 


with error messages to the client. 


On each connection between a pair of browsers, audio, video, and 
arbitrary data can be sent. Although WebRITC is peer-to-peer connections, the 
client's browser must first signal to a PeerJS server to get connection information 
that is based on a session description protocol (SDP). WebRTC uses SDP to 
describe a session profile, which contains information such as transportation 
address, media information, and related metadata. Browsers use this session 
profile to create peer connections. PeerJS provides PeerServer on Cloud, a 
public server that everyone can use by registration on the PeerJS Website, and 


PeerServer application for installation in a private network. 


b. Framework 


This thesis used PeerJS to create a data channel to interchange DIS 
messages between peers. The framework is in Figure 3. Before a peer-to-peer 
connection, each peer has to initially connect to a PeerServer to get another 
peer’s information and a web server to receive web content. Once the peer 
browsers construct data channels and receive web content, the peers no longer 


need the PeerServer. 
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Figure 3. WebRTC networking framework. 


B. PERFORMANCE WITH WEBGL 


WebGL is one of the critical elements in web-based simulation. Users feel 
more immersed if a simulation has lifelike models, especially 3D models in a vivid 
virtual environment. Running 3D graphics, however, is resource consuming, 
which means computers have to devote lots of CPU or GPU resources to 
computing the change of 3D graphics (e.g., movement, scaling, rotation). 
Therefore, this thesis designed a comparison for applying WebGL or not. All the 
experimental 3D models were made with Blender, which is free and open-source 
software for computer 3D graphics. Blender has an add-on function to export 3D 
graphics, and a library implemented WebGL (three.js), which has loaders for 


importing .js models into web pages. 


1. Without WebGL Elements 


Purely DIS messages send and receive without WebGL elements in 
different networking frameworks. In order to find out the capability of sending and 
receiving speed in modern browsers, two browsers were opened on two 
computers with the same hardware devices; one was for sending DIS packets 
and the other was for receiving DIS packets. The sending browser repeatedly 
converted an ESPDU JavaScript object to binary format DIS messages before 


sending those messages. The receiving browser decoded the binary message, 
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converted it a JavaScript object and distinguished PDU types every time it 


received DIS messages. 


2. With WebGL Elements 


WebGL enables web browsers to render 3D graphics without plugins, but 
it also takes a lot of computational resources. This thesis created a 
demonstrating game that used WebGL and the three.js library to render 3D 


graphics and DIS PDUs to exchange entity information. 


a. 3D Models 


This thesis designed three major 3D models (terrain, tank and tank 
ammunition) to demonstrate the feasibility of web-based simulation. The 
demonstration was a simple and first-person-shooter tank game. The players 
controlled a single tank to search, aim, and shoot other tanks in a virtual 
environment in a web browser. This game was designed for multiple players. 
Each player, and each browser page, created its own virtual environment 
(including scene, skybox, light, camera, terrain, a controllable tank, tank 
ammunition, etc.) when the browser connected to a web server and got the game 
html file. Browsers started sending and receiving DIS messages once they 
connected to a WebSocket gateway server or established a WebRTC data 
channel. Other tank models and ammunition models were created when a 
browser received ESPDUs whose entity IDs were new to that browser, which 
meant that each opponent tank model had a corresponding entity ID. If an 
incoming ESPDU's entity ID already had a representative 3D object, the browser 


would update the state and location of this 3D object in the virtual world. 


b. Game Design 

There are three different types of DIS PDUs in this tank game: entity state 
PDU (ESPDU), collision PDU and fire PDU. Figure 4 describes the mechanism of 
this tank game. The upper section is about sending DIS PDUs, and the lower 


describes receiving DIS PDUs. When the game started and a controllable tank 
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was created in the scene, the tank could move and search for targets. At the 
same time, the tank issued ESPDUs every ten milliseconds, which was the same 


rate at which WebGL updated its canvas. 


The ESPDUs are the major interchanging PDUs in DIS simulations, and 
contain all the basic information of entities (e.g., entity ID, entity type, entity 
location, and entity orientation). The collision PDU contains information about 
collision events, and is issued when a collision happens between two simulated 
entities or between a simulated entity and another object in the virtual world. In 
this tank game, a collision PDU was issued only when a tank’s projectile hit 
another tank. The fire PDU is used to support visual, aural, and other effects, and 
identify an entity that fired a weapon or expendable. The fire PDU in this game, 
however, was only used to communicate firing events and showed the firing 


information on screen. 


To play this game, the player has to eliminate all other tanks in the virtual 
battlefield. If a tank gets hit while searching for targets, it will issue a collision 
PDU. The information in a collision PDU includes the issuing entity ID, colliding 
entity ID, event ID, location, etc. If a tank finds a target and shoots it, the tank will 
issue a fire PDU regardless of whether it hits its target. A fire PDU contains the 
fields firing entity ID, target entity ID, location, etc. for describing the firing event. 
lf a tank hits a target, the tank’s projectile will issue a collision PDU. In the 
receiving section, when the browser receives a DIS message, the message will 
be decoded and categorized into ESPDU, collision PDU or fire PDU. If a browser 
receives an ESPDU and the ESPDU’s entity ID is new to this browser, the 
browser loads a 3D object to represent this entity ID. Otherwise, the browser 
updates the state and location of this 3D object. If browsers receive fire PDUs, 
they display the fire information in the upper-left corner of the window. If a 
browser receives a collision PDU, it checks whether its controllable tank issued a 
collision PDU within two seconds (a game setting). If the answer is yes, the tank 


is killed, and the game is over. If no, there might be some latency or lag in 
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networking traffic that created an asynchronous situation, so the game would 
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C. PERFORMANCE IN DIFFERENT BROWSERS 


Modern browsers such as Chrome, Firefox, and Safari use different 
JavaScript engines to execute JavaScript. Chrome uses V8 as its JavaScript 
engine. V8 is an open-source and high-performance JavaScript engine that is 
written in C++ and implements ECMAScript as specified in ECMA-262, 5th 
Edition (“Chrome V8,” n.d.). V8 can be run on most modern operating systems 
such as Windows (XP or newer), Mac OS X (10.5 or newer) and Linux systems. 
Firefox's JavaScript engine is called SpiderMonkey, which is written in C/C++ 
(“Firefox SpiderMonkey,” n.d.). The latest JavaScript just-in-time (JIT) compiler 
for SpiderMonkey is called lonMonkey, which is implemented in the latest Firefox 
browser and can be installed in most modern operating systems. Safari uses 
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another JavaScript engine Nitro, but this thesis did not use Safari for experiments 


because Safari does not support WebRTC yet. 


Different JavaScript engines cause variations in browser performance. 
There are many web applications for benchmarking JavaScript performance 
among different versions of browsers or different brands of browsers, including 
SunSpider, Kraken, and Octane. The benchmarking tests are varied, and it is 
hard to measure the performance precisely because there are too many 
variables (e.g., CPU, memory, browser version) to affect the benchmarking 
results. The common benchmarking tests include OS kernel simulation 
benchmark, 3D ray tracer, cryptography test, code decompression, PDF reader 
implementation, etc. There is an existing website showing benchmarking 
comparisons between modern browsers within different operating systems, and 
the website visually displays the differences among those modern browsers 


(“Arewefastyet,” n.d.). 


Currently, WebSocket is supported widely by almost every browser 
(Deveria, n.d.-c). WebRTC is supported by a few browsers, including Chrome, 
Firefox, and Opera. The global usage of Chrome, Firefox and Opera is 28.39%, 
4.69% and 0.36%, respectively (Deveria, n.d.-b). Therefore, the comparison of 
performance between browsers mainly focuses on Chrome and Firefox in this 


thesis. 
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IV. IMPLEMENTATION 


In order to implement experiments, four services were run on the server 
side: WebSocket gateway, web service, PeerServer and primary peer. The 
experimental environment can be divided into two parts: WebSocket and 
WebRTC. This thesis, however, used one computer to run these four services. 
Figure 5 shows the experimental environment for this thesis. The first part was 
client-server framework using WebSocket gateway server. The server, which 
was downloaded from the Open-DIS project website, provides web server and 


server-side implementation of WebSocket. 


Second part was peer-to-peer framework using PeerServer. PeerServer 
only has the capability to help broker connections between peers, so the 
experiments in this thesis used the web server from WebSocket gateway server 
for users to download web content, WebGL elements, 3D models and JavaScript 
code. One of the features of PeerJS is using unique IDs to make peer 
connections, so the newly-joined peer has to obtain the IDs of others to create 
peer connections beforehand. The primary peer was a webpage that collected 
the peer IDs and distributed a list of live peers to all connected peers. Although 
every client has a data channel with the primary peer, they would not send any 
DIS packets to the primary peer. A connected peer list was the only distributed 


data under this data channel. 
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Websocket gateway server Client A Client B 
Web server 

PeerServer with Node.js 
Primary peer 















Ethernet 






Figure 5. Experimental environment. 


A. SERVER PREPARATIONS 


The following section describes preparatory works for the above- 
mentioned four services that were used to support the performance tests in this 


thesis. 


1. WebSocket Gateway Server and Web Server 


WebSocket gateway server ran on a computer with NetBeans installed. 
This server also had the capability of web server, so clients could get web 
content from a server IP address on port 8282. Port 8282 is a default setting for 
this server. This server also can receive native DIS messages that were 
broadcast from other simulation systems using UDP socket with port 3000, but 
this function was turned off manually in the experiments. The WebSocket was 
client-server architecture, so the expression in Figure 5 was that Client A sent 
DIS messages to WebSocket gateway server and then the server distributed the 


receiving DIS messages to Client B, and vice versa. 


24 


2. WebRTC: PeerServer and Primary Peer 


PeerServer is Node.js-based application, so the server computer must 
install Node.js before running PeerServer. Node.js is a V8 (JavaScript engine) 
based platform for developing fast and scalable network applications. Figure 6 
shows how to install and execute PeerServer after having Node.js installed. 
Node.js can be obtained from its official website: http://nodejs.org/. PeerServer 
used port 9000 to help broker connections between peers. The primary peer was 
one of PeerServer clients, so the primary peer could be executed after 
PeerServer was on. WebRITC its peer-to-peer connection with a rendezvous 
server; the framework is shown in Figure 3. 


Microsoft Windows ([Yersion 6.1.7681 } 
Copyright ¢c>? 2609 Microsoft Corporation. All rights reserved. 


Eee Ue ea a ee 


CiWsers‘\Administrator‘node_modules\.bin?>peerjs --port 9600 --key peerjs 
Sr ee ee ee Oe | es i 





Figure 6. Install and execute PeerServer. 


B. BROWSER INITIATIVE PROCESSES AND BEHAVIORS 


Once the server and services were established, client browsers could 
connect to the server to receive web contents. The web contents helped the 
browsers initiate a virtual world inside the window and interact with users. The 
initiative processes included importing necessary libraries; checking browser 
brands, and creating a canvas, scene, virtual objects, etc. Once the browser was 
initiated, it began sending and receiving DIS PDUs via WebSocket or WebRTC 
data channels. At the same time, the browser was ready to interact with users via 
the computer keyboard. The following describes the processes of initiating web 
browsers and the behaviors of exchanging DIS packets and interacting with 


users. 
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1. Import Libraries 


The “dis.js’ archive is an essential library for experiments in this thesis, 
and it can be downloaded from the Open-DIS project. It includes all DIS PDU 
classes and methods that convert from DIS PDU objects into binary format DIS 


and vice versa. 


a. WebSocket 


WebSocket is a native capability in web browsers that support WebSocket, 


So no specific library needs to be imported for WebSocket. 


b. WebRTC 


WebRTC is included in the web browser, and PeerJS wraps the browser's 
WebRTC implementation. This thesis used PeerJS as an API to create 
WebRTC data channels, so the “peer.js” library obtained from the PeerJS 


official website must be imported at the beginning. 


C. WebGL 


WebGL is native in browser. This thesis applied “three.js,” which is layered 
on top of WebGL as a library for 3D graphics in web browsers (Parisi, 2012). It 
can be used to create scene graphs, camera, light, skybox, and basic 3D 
graphics, and it also can manipulate imported 3D models by applying different 


materials or shaders. 


d. Others 


Other libraries included OrbitControls.js as well as various loader and self- 
defined js archives. OrbitControls.js was used to control the camera by mouse in 
browsers, and the different loaders were for loading different formats of 3D 
models such as obj, js, mtl, and max. Figure 7 shows the relationships of 


importing libraries and other JavaScript programs. 
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a <script> 
Application Tank Game 


</script> 


Other js files | heartbeat.js |{ three.js_ 


Networking peer.js 
Frameworks Websocket 
WebRTC 





Figure /. Relationships of importing libraries and other JavaScript programs. 


2: Checking Web Browser Brand and Initiating WebSocket or 
WebRTC 


Different browsers have different engines to implement JavaScript, so 
when an end user downloads web content from a web server, JavaScript code 
must check what kind of browser is being used. WebSocket and PeerJS that 


implements WebRTC have different ways to check browser brands. 


a. WebSocket 


WebSocket is widely supported by many browsers. The main browsers 
this thesis had to differentiate were Chrome and Firefox. Figure 8 shows the 
JavaScript code for distinguishing browser brands and establishing a connection 


to the server. 


if(window.WebSocket) 

websocket = new WebSocket("ws://websocket.example.com:8282"):; 
else if(Window.MozWebSocket) 

websocket = new MozWebSocket("ws://websocket.example.com:8282"); 
else 

alert("This web browser does not support web sockets"); 


Figure 8. Creating WebSocket code. 
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b. WebRTC 
The WebRTC is wrapped by the PeerJS API, and it automatically checks 


browsers for web application developers. To initiate a peer object, a user has to 
randomly produce a peer ID to signal to the PeerServer, and then wait for a 
connection from other peers. If the ID is not given, the PeerServer will generate 
one for this client. Figure 9 shows the code for creating a peer object and 


signaling to PeerServer. 


peer = new Peer( peerlID, {host: PeerServer.example.com, port: 9000 }); 


Figure 9. Initiate a PeerJS client. 


There are two situations for creating peer connections: pre-known the ID 
of prospective peer and unknown the ID of prospective peer. Figure 10 shows 
the architecture and sequence of creating connections among peers for 
performance tests in this thesis. The following three steps describe the 
mechanism of creating peer connections in the situation of an unknown 
prospective peer ID. This thesis uses the primary peer to help distribute an ID list 
to all connected peers. If the peer ID, however, is pre-known, a peer can create a 
peer connection to another peer directly with the help of PeerServer. For 
example, in Figure 10 the game client A creates a peer connection to primary 
peer because client A has known the ID of primary peer beforehand. Only the 


following step 1 and step 2 are involved in this case. 


Step 1: The primary peer maintains a list of all the peers connected in the 
tank game. It must be running before any game clients start. When game clients 
begin execution, they contact the primary peer and provide their IDs. The 
Primary Peer in turn informs the game clients of the IDs of other peers. This 


allows the game clients to establish pair-wise connections for communication. 


Step 2: When the first game client starts, it first contacts the PeerServer to 
get the information necessary to establish a connection to the Primary Peer. It 


then connects the Primary Peer and provides its ID. 
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Step 3: When a second game client starts it also first contacts the Peer 
server as the first step for contacting the Primary Peer. It contacts the Primary 
Peer and provides its ID, and is in turn informed of the IDs of all other game 
clients. Any other game clients are informed of the ID of the new game client. All 
game clients can then establish pairwise connections between each other. The 
tank game client A established a WebRTC connection to game client B, and 


game client B establishes a connection to game client A. 


In reality, each connection is a bidirectional channel. For example, if client 
A established a connection with client B, client B could use this connection to 
exchange data with client A. This thesis, however, constructed two data channels 
between each pair of clients for convenient configurations of sending and 


receiving behaviors. 


Primary peer 


Signaling 


Primary BaarSenve Game Game 
peer | client A client B 
—————— > 


© S 
, 


Server side 


Session profile 





Signaling 







Session profile 


Creating peer connection 


—_ ee 
Sending ID list 





PeerServer 


Signaling 


Session profile 


Game clientA Game client Creating peer connection 
fc @ Cc S Sending ID list to both client A and client B 
_——_—————_—————— 
Creating peer connections 
<_ 
Figure 10. Architecture and sequences of creating peer connections. 
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3. Create Canvas, Scene, Camera, and Own Entities 


HTML5 has a “canvas” element for drawing 2D and 3D graphics on web 
pages, and the three.js library provides methods to create and display animated 
3D computer graphics on browsers that support WebGL. Figure 11 shows the 
codes to create a canvas and Figure 12 shows the basic elements in the scene. 
Every computer graphical elements—such as 3D graphics, light and camera— 


were added into the scene in the tank game. 


At the same time, a controllable tank model was loaded by the JSON 
loader after the scene was created, and two JavaScript objects were created. 
One was to contain this controllable tank and an ESPDU that represents the 
states of this tank. Another object comprised a tank’s ammunition mesh and a 
different ESPDU that restored information of this ammunition. Figure 13 shows 
codes of JavaScript objects that contained the tank object and its corresponding 
ESPDU. It also shows some numbers were assigned in the field of entity type. 
These numbers were used to identify military hardware, and they referred to a 
SISO document called the “Enumeration and Bit Encode Values” (EBV). The 
EBV document is a long listing of standardized enumeration for simulation 
interoperability (Simulation Interoperability Standards Organization (SISO) 


Reference for: Enumerations for Simulation Interoperability, 2013). 


<body> 
<div id="container'> 
<canvas style="width:100%;height:95%;border:1px gray solid;"> 
</div> 
</body> 


Figure 11. Creating canvas in a web page. 
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var mycanvas = document.getElementsByTagName("canvas")[0]; 
var w = mycanvas.clientWidth; 
var h = mycanvas.clientHeight; 
scene = new THREE.Scene(); 
camera = new THREE.PerspectiveCamera( 
30, // Field of view 
w/h, // Aspect ratio 
0.1, //Near 
10000 // Far 
1 


scene.add(camera); 


var light = new THREE.PointLight( OxFFFFFF ); 
scene.add( light ); 


var ambient = new THREE.AmbientLight( 0x222222 ); 
scene.add( ambient ); 


Figure 12. Creating scenes and adding graphical elements. 


var ourEntity= {}; 

var loader = new THREE.JSONLoader(); 

ourEntity.tank = new Tank(loader); 

ourEntity.lastEspdu = new dis.EntityStatePdu(); 
ourEntity.lastEspdu-entityType.entityKind=1; //Platform 
ourEntity.lastEspdu.entityType.domain = 1; //Land 
ourEntity.lastEspdu.entityType.country= 225; //U.S. 
ourEntity.lastEspdu.entityType.category = 1; 
ourEntity.lastEspdu.entityType.subcategory = 1; 
ourEntity.lastEspdu.entityType.spec = 3; 
ourEntity.lastEspdu.entitylD.entity = Math.round(Math.random() * 20000); 


Figure 13. Creating tank meshes and ESPDUs in ourEntity objects. 


4. Game Control and Graphics Rendering 


Human-in-the-loop simulations must contain input devices for users to 
give orders, and all the web applications are run on computers and mobile 
devices. The development of this thesis’s demonstration was based on using the 


keyboard and mouse as input devices. Players used the keyboard to control the 
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tank, fire missiles, and switch cameras; they used the mouse to change player 
perspective views. JavaScript provides corresponding key codes that are 
associated with keyboard characters for web application developers to develop 
different functions in different keys (Lautenschlager, n.d.). JavaScript also 
provides event handlers for keydown and keyup events in the window. The 
example tank game used keys “W” and °“S” to move the tank forward and 
backward, keys “A” and “D” to turn the tank left and right, keys “Q” and “E” to 
adjust the tank’s barrel, key “Space” to fire a missile, and keys “1” and “2” to 
switch cameras. Figures 14 and 15 show examples of using JavaScript key 


codes to program different actions. 


function cnkeyOown(evt, 
switch (evi. keyCode 
| 
case 49; //'1' //cameral 
camera = cameral; break; 
case SO: f/'2' // camerazZ 
camera = camera?: break: 
case 65: //'a' 
curEntity.tank.rotationSpeead = +1.0;break 
case 68: //'d' 
ourEntity.tank.rotationSpeed — «1.0; break, 
case BF: ff w 
OUrEMLity.tank.translationsSpeed= +10.0; break: 
case 63: f/f 's' 
curentity.tank.translationSpeed= -10.0; break; 
case &1: //'q' /felevate barrel 
ourEntity.tank.elevateSpeed = 0.5; break; 
case 69: //'e' ffelevete 
ourEntity.tank.elevateSpeed = -0.5: break: 
case 32: //spacahar !/Fire 
r(ourMuniztionEstity. munition .missileReadyForshooting) 
[ 
munitionFire = true; 
munilinsendCullisiawPuu = leue; 
ourMnitionEntity, munition, missileShoot= true; 
ibreak: 


Figure 14. Function of keydown events. 
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function onKeyUp(evt) 


{ 
switch (evt.keyCode | 
{ 
case 65: // ‘a’ 
ourEntity.tank. rotationSpeed = 0.0; break; 
case 68: //'d' 
ourEntity.tank. rotationSpeed = 0.0; break; 
case B?: ff 'w' 
ourCntity.tank.translationSpeed = 0.0; break; 
case 83: //'s' 
ourEntity.tank. translationSpeed = 0.0; break; 
case 81: f/f 'q' 
ourEntity.tank. elevateS peed = 0_0; break; 
case 64: // ‘a 
ourEntity.tank. elevateS peed = 0.0: break: 
I 
}; 


window.onkeydown = onKeyDown; 
window.onkeyup = onKeyUp; 


Figure 15. Function of keyup events and window event handlers. 


The frequency of rendering 3D graphics affects the fluidity of the game. 
Most video games use 30 frames per second (fps) or 60 fos and some, such as 
Halo3, are locked at 30 fos maximum (“Frame rate,” n.d.). JavaScript provides a 
setinterval method that repeatedly calls a function in a specific interval. In the 
tank game, the rendering frequency was set to ten milliseconds, which equals to 


100 fps, and all the game events and animations were based on that timestamp. 


5. Convert Coordinate Systems 


The DIS uses the ECEF (Earth-centered, Earth-fixed) coordinate system, 
which defines point (0, 0, 0) as the center of the earth. The positive x-axis is 
defined as running from this point out to where the equator and the Prime 
Meridian intersect. The positive y-axis runs from the center point out to where the 
equator intersects the 90 degree east meridian, and the positive z-axis points 
from the center toward the North Pole. The “dis.js” library provides methods to 


convert coordinates between ECEF and ENU (east, north and up), which is a set 
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of local coordinates with a given geodetic point. Figure 16 presents the 
coordinate systems of ECEF and ENU. The “dis.js” also helps convert between 
ECEF and latitude, longitude and altitude. 


The tank game is a Self-interactive game, which means players are always 
in the same local coordinate system. The game, however, still converts its local 
coordinates from ENU to ECEF in case other DIS simulations want to 
communicate with it in the future. Besides the conversion of location, the entity's 
orientation must also be converted. Rotation in three.js is based on quaternion, 
which uses four numbers to represent an entity’s orientation in a 3D world. On 
the other hand, ESPDU only provides three fields that are Euler angles to 
express orientation. There are many examples of conversion between quaternion 
and Euler angles on the Internet. Figure 17 is an example of a conversion 


between coordinates. 


face 


Vos wi 





Figure 16. Earth centered, earth fixed; and east, north, up coordinates 
(“Axes conventions,” n.d.) 
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var rangeCoordinates = new dis.RangeCoordinates(0.0, 0.0, 0.0); 


// convert from local coordinate system to global coordinate system. 
var localToGlobal = function (entity) 


{ 


Hh 


var entityPosition = {x:entity.tank.mesh.position.x, 

y:entity.tank.mesh.position.y, z:entity.tank.mesh.position.z }: 
var toGlobalCoordinates = rangeCoordinates.ENUObjectToECEF(entityPosition); 
entity.lastEspdu.entityLocation.x = toGlobalCoordinates.x: 
entity.lastEspdu.entityLocation.y = toGlobaiCoordinates.y; 
entity.lastEspdu.entityLocation.z = toGlobalCoordinates.z; 


//orientation 
var pitchYawRoll= quatToEuler(entity.tank.mesh.quaternion); 
entity.lastEspdu.entityOrientation.theta = pitchYawRoll.y; 


//convert from global coordinates to local coordinate system. 
var globalToLocal = function(mesh, espud) 


{ 


var localCoordinates= rangeCoordinates.ECEFObjectloENU(espud.entityLocation); 
mesh.position.x = localCoordinates.x; 
mesh. position.y = localCoordinates.y; 
mesh. position.z = localCoordinates.z; 


//orientation 
mesh.rotation.y = espud.entityOrientation.theta; 


Figure 17. Conversion between ECEF and ENU. 


6. Send DIS Packets 


DIS simulation uses heartbeat strategy that periodically sends DIS 
packets to update entity information and maintain entity existence; the “dis.js” 
library provides methods to convert every DIS PDU from JavaScript object into 
binary format DIS messages. In the demonstration tank game, entity state PDUs 


were sent periodically to the server or other PeerJS clients. 


Collision PDU and fire PDU, on the other hand, are event-oriented. 
Collision PDUs were issued when there was a collision event between a tank 


missile and opposing tank. Fire PDUs were issued whenever someone was 
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shooting. The periodic sending of DIS PDUs also helped maintain entity 
existence in other clients, because each client browser would check the receiving 
time for every entity. If an entity's last receiving time was 3 seconds ago, which 
was a game setting, this entity would be removed from client browsers. Figure 18 
shows example code of a heartbeat function in setlInterval method, and a 


trimmed DIS message that was transferred via the WebSocket. 


var heartbeat = function() 


{ 
var dataBuffer = new ArrayBuffer(1500); 
var outputStream = new dis.OutputStream(dataBuffer); 
ourEntity.lastEspdu.encodeToBinaryDIS(outputStream); 
var trimmedData = dataBuffer.slice(O0, outputStream.currentPosition); 
websocket.send(trimmedData); 

}; 


// Periodically send heartbeat messages 
setinterval(heartbeat, 10); 


Figure 18. Heartbeat function. 


PeerJS uses a similar method to send DIS messages, but the sending 
mechanism is via PeerJS DataConnection object. Figure 19 shows how to create 
a DataConnection object from a peer object, and the sending method. The 


trimmedData is the same with WebSocket. 


var connectTo = peer.connect(‘other peerID'); 


connectTo.send(trimmedData); 


Figure 19. PeerJS sending method. 
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7. Receive and Decode DIS Messages 


The codes used to receive data are different between WebSocket and 


PeerJS. The decoding processes, however, are the same. 


a. Receive by WebSocket 


Before receiving data from WebSocket, the format to receive binary 
messages and attach functions for various events must be set. Figure 20 shows 
the code for setting the WebSocket. WebSocket.onmessage is the function used 


to handle receiving data from the server site. 


websocket.binaryType = ‘arraybuffer'’; 


websocket.onopen = function(evt){console.log("“websocket onopen’);}; 
websocket.onclose = function(evt){console.log("websocket close");}: 
websocket.onerror = function(evt){console.log("“websocket error");}; 
websocket.onmessage = function(evt){ 

// Handle received DIS messages here 


}; 
Figure 20. Set format and attach functions. 


b. Receive by PeerJS 


After creating a peer object, developers have to set listeners for peer 
events. The main method this thesis used was “peer.on,’ and the listening event 
was “connection, with a function to handle the incoming messages. This event 
will receive a dataConnection object, which wraps WebRTC’s DataChannel, and 
pass this object to the handling function. Figure 21 shows the code to listen for 


events. 
peer.on(‘connection’, function(dataConnection) {... }); 


Figure 21. PeerJS event listener. 


3/ 


The DataConnection class contains three methods: “send,” “close” and 
“on. The “send” method sends data to the remote peer, and “close” closes the 
data connection and cleans up underlying DataChannels and PeerConnections. 
The “on” method can be set for listening for data connection events: “data,” 


“open, “close” and “error.” The thesis experiments used the “data” event that is 
emitted when data is received from remote peers to receive and handle DIS 


messages. Figure 22 shows the example code. 


peer.on(‘connection’', connect); 


function connect(connReceived) { 
var peerld = connReceived. peer; 
console.log(‘remote peer id: ',peerld); 


connReceived.on(‘data’', function(data){ 
//Handle received DIS messages here 


}); 
connReceived.on(‘close’,function(){ 
delete connectedPeers|[peerld]; 


‘ih 
} 


Figure 22. Example code of receiving events function. 


C. Decoding DIS Messages 


The mechanism of decoding DIS packets is the same in WebSocket and 
WebRTC because both rely on the “dis.js” library to interpret DIS messages. The 
function of the WebSocket and the WebRITC is to send and receive application 
data. The first step in interpreting DIS messages is to allocate packets to 
different types of PDUs using a method called dis.PduFactory(). Different PDUs 
contain different information with different data lengths. Every PDU, however, 
has the same PDU header, which has 96 bits to restore basic information such 


as protocol version (8-bit enumeration), exercise ID (8-bit unsigned integer), and 


38 


PDU type (8-bit enumeration). The dis.PduFactory() method uses the PDU type, 
which is the third byte in the PDU header, to distinguish what kind of PDU should 
be assigned. The demonstration game in this thesis used three different types of 
PDUs: entity state PDU, collision PDU, and fire PDU. The respective lengths of 
these three DIS PDUs are 1152 bits, 480 bits and 768 bits, and the respective 
enumeration numbers of these three PDUs are 1, 4, and 2. Figure 23 shows how 


to use dis.PduFactory(). 


var pduFactory = new dis.PduFactory(); 
var newPdu = pduFactory.createPdu(evt.data);//Websocket 
var newPdu = pduFactory.createPdu(data);//PeerJS 


Figure 23. Example code of dis.PduFactory(). 


After differentiating the PDU type, it is time to deal with receiving the DIS 
messages: entity state PDU, collision PDU, and fire PDU. ESPDU is used to 
update entity states in client browsers. Every client would create a JavaScript 
object, which is used to record all remote entities from other game participants. If 
the receiving ESPDU's entity ID did not previously exist, client browsers will 
recode the new ESPDU in an all-remote-entity object, and create a 
corresponding 3D model loaded by JSON loader to represent this entity ID. If 
there is a 3D model having the same entity ID corresponding with the receiving 
ESPDU, browsers will update this 3D model's states such as location, velocity, 
and orientation. Collision PDUs will be issued when a collision occurs between 
entities. In the demonstration tank game, collision PDUs were issued whenever a 
tank got hit; both the firing missile and the hit tank issued collision PDUs. Fire 


PDU in this scenario was for showing all firing events on the screen. 
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8. Miscellaneous 


There are some miscellaneous things that have not been mentioned, but 
which are also very important for creating a browser-based DIS simulation. 
These include how to load meshes, how to detect collision in a_ virtual 
environment, how to ensure entity existence, and the application of dead 


reckoning. 


a. Loading 3D Objects 


Creating the 3D graphics took longer than creating a JavaScript object. 
When a client browser received an ESPDU whose entity ID was new to this client, 
the client would create a 3D model to represent this new entity. The 3D model, 
however, could not be located immediately in the virtual world before it was fully 
loaded. In the tank game example, a function continued updating entity states 
and the corresponding 3D model each time the clients received the same 
ESPDUs. Once the 3D model was fully loaded into the virtual world, an opposing 
tank would show in the browser. The following code describes a way to update 
entity and 3D model properties. Figure 24 shows the code of updating the entity's 


model and states. 
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var updateEntityMesh = function () 
{ 
for(var e = 0; e < needUpdateEntityArray.length; e++ ) 
{ 
var needUpdateEntity = needUpdateEntityArray.shift(); 
for(var eidString in allEntities) 
{ 
var currentEntity = allEntities[eidString]; 
if(eidString === needUpdateEntity) 
{ 
if(currentEntity.munition) 
{ 


if(currentEntity.munition.mesh) 


{ 


if(currentEntity.lastEspdu.entityType.entityKind === 2) 


globalfoLocal{currentEntity.munition.mesh, currentEntity.lastEspdu); 
DeadReckoningParameterGlobalToLocal(currentEntity.munition, currentEntity.lastEspdu); 
allEntities[eidString] = currentEntity; 
} 
} 
} 
if(currentEntity.tank) 
{ 
if(currentEntity.tank.mesh) 
{ 
eloballtoLocal(currantEntitytank.mesh, currantEntity.lastEspdu): 
allEntities[eidString] = currentEntity; 


Figure 24. Code of updating entity states and 3D model. 


b. Entity Collision Detection 


The “three.js” library provides methods for ray casting that can be used to 


detect collision in a virtual world. The way of using ray casting is to push all 
prospective collided objects into an array before doing ray casting. In the 
demonstration game, ray casting was used for checking collisions between: tank 
and terrain, tank and tank, and tank and skybox. Tanks cast a ray to minus the y- 
axis (1.e., toward the ground), so that they could rise and fall on (i.e., “follow’) the 
terrain by having a collision between tank and terrain. Tanks also cast rays in 
another four directions—front, rear, right, and left—for detecting other tanks and 


any vertical terrain. Ray casting in this game was used not only for collision 
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detection, but also for pointing out missile directions: shooting a ray from a turret 
to find a collision point, and then using this point to determine projectile path by 


computing between colliding point and turret. 


C. Checking Existence 


The DIS is a heartbeat-based simulation, so every client should receive 
ESPDUs periodically from other clients. There is a field in the PDU header for 
timestamp. This field can be used to record the last time heard from other 
ESPDUs. If a simulation participant did not receive ESPDUs from remote peers 
in a period-of-time, the participant removed 3D models and properties that 
belonged to those remote peers. There were six elements removed when the 
client browser did not hear any ESPDU from a specific peer: tank mesh and 
ammunition mesh in the scene, tank, and ammunition properties in the all- 


remote-entity object, and tank and ammunition objects in the collision array. 


d. Dead Reckoning 


Dead reckoning is used to predict an entity's next position by using the 
entity's current position with a dead-reckoning algorithm, linear acceleration, 
angular velocity, and other parameters when the entity does not receive the next 
prospective ESPDUs to update its position. Dead reckoning can be utilized to 
cover an entity's stutters caused by the heartbeat period. The demonstration tank 
game used dead reckoning for a projectiles movement to reduce visual jumping, 
in-browser, of other game participants. A projectiles movement with dead 
reckoning that complements intervals between two consecutive ESPDUs also 
increases the accuracy of issuing collision PDUs, because the heartbeat strategy 
might cause the projectile to “jump” over an opponent's tank without any collision 


or intersection. 
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V. PERFORMANCE TESTS 


This thesis investigated two networking frameworks, WebSocket and 
WebRTC, and used these two frameworks in performance experiments and the 
resulting data. The WebSocket was constructed as client-server architecture. In 
contrast, the WebRTC was based on peer-to-peer architecture after a data 
channel was constructed. This thesis also incorporated WebGL components as a 
comparable factor, which compared the presences of WebGL components in the 
browser. WebGL enabled the browser's rendering of 2D and 3D graphics, but it 
also increased CPU and GPU loadings by computing graphics transformation, 
scaling, rotation, translation, etc. Furthermore, different browsers used different 
JavaScript engines, so the differences between the browsers (Chrome version 
36.0.1985.143m and Firefox version 24.7.0) were compared. Measuring tools for 
this thesis included self-created functions, Chrome developer tools, and Firefox 


developer tools. 


A. SENDING AND RECEIVING ABILITY 


To measure the sending performances in different networking framework 
and browsers, this thesis created a function to send ESPDU packets. The 
receiving numbers were increased when the onmessage function was called and 
packets were received by the WebSocket. The PeerJS received PDUs when the 
dataConnection object heard ‘data’ events. Figure 25 shows the measureDIS 
function for sending DIS packets in WebSocket. The measurement evaluated 
how much time was needed for sending 10,000 DIS packets, with millisecond as 
the time unit. The function had a ‘sendercounter’ variable to cumulate the total 
number of sending. At the same time, this function also converted the total 
number to a serial number for dropping test into the entityAppearance field in 
ESPDU. PeerJS used connectTo (a dataConnection object) to send the trimmed 
data (see Chapter IV, Section 6, Send DIS Packets). 
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var measureDI5 = function() 


{ 


ourEntity.lastEspdu = new dis.EntityStatePdu(); 
startTime = new Date(); 

senderCounter = 0; 

while(senderCounter < 10000) 


{ 


I 


ourEntity.lastEspdu.entityAppearance = totalSend+1; 

var dataBuffer = new ArrayBuffer(1500); 

var outputStream = new dis.OutputStream(dataBuffer); 
ourEntity.lastEspdu.encodeToBinaryDIS(outputStream); 

var trimmedData = dataBufferslice(0, outputStream.currentPosition); 
websocket.send(trimmedData); 

senderCounter ++; 

totalSend +4; 


endTime = new Date(); 
var elapsedTime = endTime getlime() - startlime_getTime(): 
console.log("time:", elapsedTime, "send packets:", senderCounter): 


Figure 25. 


MeasureDIS function for sending DIS packets. 


Figure 26 shows the example of a WebSocket receiving DIS packets. The 


measurement was the same with the sending function that measured how much 


time was needed for receiving 10,000 PDUs. Figure 27 shows the method that 


the PeerJS used to receive data. 


websocket.onmessage = function(evt) 


{ 


hi 


Figure 26. 


receiveCounter++; 

totalReceive ++; 

if(receiveCounter === 1){startTime = new Date();} 
if(receiveCounter % 10000 === 0) 


{ 


var endTime = new Date(); 
var elapsedTime= endTime.getTime() - startTime.getTime(); 


console log|"time:", elapsedTime, "receive packets:", receiveCounter); 
receiveCounter = 0; 
startTime = new Date(); 


Measuring function of receiving DIS packets in WebSocket. 
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connReceived.on(‘data', function(data) 


{ 
//same with websocket onmessage. 
receiveCounter++; 
totalReceive ++; 
if(receiveCounter === 1){startTime = new Date();} 
}); 
Figure 27. Measuring function of receiving DIS packets in PeerJS. 


The following section shows the transformed outcomes of running the 
above functions 20 times based on a one-on-one situation, one sender, and one 
receiver. As a result, 20 runs of a specific time were spent on sending and 
receiving 10,000 PDUs. The thesis used MS Excel to convert the results into the 
number of Entity State PDUs that were sending and receiving per second, and 


used JMP for statistics. 


Figure 28 shows the outcome of pure sending and receiving rates in 
different combinations of browsers. The left eight experiments are receivers, and 
the remaining experiments are senders. The green lines are the means of each 
experiment, and the blue bars can be used to visually compare the statistical 
difference between any pair of experiments. If a pair of bars overlaps from each 
other, these two experiments are not significantly different, and vice versa. CC 
means that the Chrome browser sent to the Chrome browser; CF means the 
Chrome browser sent to the Firefox browser, and so on. Figure 28 shows that 
senders were overwhelmingly faster than recipients, because the sending rates 
were counted by executing the measureDIS function instead of actually sending 
out to the browsers. In addition, none of the experiments found message losses 
in the WebSocket framework, and rarely were the DIS packets lossed in the 
WebRTC framework. The sending data was not sent out by browsers; instead, it 
was queued in the senders’ memory. For example, if a sender's browser invoked 
a function that used WebSocket to send 10,000 ESPDUs per second, but the 
receiver only got 7,000 PDUs per second; the remaining 3000 ESPDUs per 
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second would buffer in the sender's memory. Hence, the performances of 
sending and receiving DIS messages in different frameworks in different 


browsers should refer to the receiving throughputs. 


Figure 29 focuses on the DIS receiving rates, and shows that the 
WebSocket had relatively stable receiving rates (around 7,000 to 8,000 per 
second in different browsers). According to the WebSocket framework—which 
was client-server architecture—the recipients received DIS packets from the 
WebSocket gateway server, which means the receiving performances are 
dependent on the server's capability. In contrast, the receiving abilities of PeerJS, 
which implemented WebRTC and were based on peer-to-peer connections, were 
varied. The recipients received around 2,000 per second in Chrome sent to 
Chrome and Chrome sent to Firefox, but had better performance of around 
11,000 to 13,000 per second in Firefox sent to Chrome and Firefox sent to 


Firefox. 
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Figure 28. Purely sending and receiving capabilities. 
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Figure 29. Purely receiving capabilities. 


According to the above conclusions, sending rates did not correspond to 
the receiving rates, so the performance with WebGL elements should focus on 
the receiving capabilities. Figure 30 shows comparisons between the presences 
of WebGL, and reveals that these were graphically different among the mean 
lines. It seems like that WebGL had some level of influence on receiving the DIS 
messages, because the receiving capabilities with WebGL elements are lower 


than without WebGL elements. 
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Figure 30. Comparisons of receiving capabilities between the presences of 
WebGL. 


To understand the differences among receiving rates, this thesis used a 
student's t-tests to find out if pairs of receiving rates were significantly different 
from one another. By looking up rates in the table of t-distribution, the p-value 
could be found to compare with the alpha level. This thesis used 0.01 as the 
aloha. If the p-value greater than the alpha, there was no significant difference 
between the comparing pair, and vice versa. The p-value only indicated the 
degree of difference; it did not indicate any better performance. Table 2 shows 
the performances of that the WebSocket framework versus the WebRTC 
framework was significantly different, because all the p-values are less than 


0.0001. The differences can be checked graphically in Figure 29. 
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combination receiving PDUs combination receiving PDUs 


CC+WebSocket 7203.79 CC+WebRTC 2212.54 <.0001 
CF+WebSocket 8212.41 CF+WebRTC 2300.51 <.0001 
<i 


Comparison between 
fe 
experimental | average number of | experimental | average number of vee 


FC+WebRTC 12917.75 FC+WebSocket 7311.62 0001 
FF+WebRTC 11239.30 FF+WebSocket 7695.37 <.0001 


Table 2. t-tests of receiving capability in WebSocket and WebRTC 
frameworks without WebGL components. The experiment at left 
had the higher performance. 





Table 3 presents paring comparisons between browsers using the 
WebSocket framework; all the p-values are greater than 0.01, which means there 
were no significant difference of receiving rates between browsers when using 
WebSocket framework. Greater p-value represents less difference between the 
comparing pair. The WebSocket framework had stable performances in both 


Chrome and Firefox browsers. 


Comparison between 
Pp. 
experimental | average number of | experimental average number of velhe 
combination receiving PDUs combination receiving PDUs 
CF+WebSocket 8212.41 CC+WebSocket 7203.79 0.2151 
CF+WebSocket 8212.41 FC+WebSocket 7311.62 0.268 


FF+WebSocket 7695.37 CC+WebSocket 7203.79 
FF+WebSocket 7695.37 FC+WebSocket 7311.62 0.636 
FC+WebSocket 7311.62 CC+WebSocket 7203.79 0.894 


Table 3. ‘t-tests of receiving capability between browsers without WebGL 
components in WebSocket framework. 


CF+WebSocket 8212.41 FF+WebSocket 7695.37 





On the other hand, Table 4 shows paring comparisons between browsers 
using WebRTC framework. In all cases, Firefox is shown to send via WebRTC 


significantly faster than Chrome does. The p-value 0.9725 indicates that using 
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the Chrome browser to send DIS packets to the Chrome browser had similar 
performance when using the Chrome browser to send DIS packets to the Firefox 
browser. The p-value 0.0395 indicates that using the Firefox browser to DIS 
packets to the Chrome browser had similar performance as using the Firefox 
browser to send DIS packets to the Chrome browser, because the alpha level 
was 0.01. These results show that the same sender had similar receiving rates in 


recipient browsers. 


Comparison between 
experimental | average number of experimental average number of |P-value 
combination receiving PDUs combination receiving PDUs 
FC+WebRTC 12917.75 CC+WebRTC 2212.54 <.0001 
FC+WebRTC 12917.75 CF+WebRTC 2300.51 0001 


FF+WebRTC 11239.30 CF+WebRTC 2300.51 
FC+WebRTC 12917.75 FF+WebRTC 11239.30 0.0395 
CF+WebRTC 2300.51 CC+WebRTC 2272.54 0.9725 


Table 4. t-tests of receiving capability between browsers without WebGL 
components in WebRTC framework. 


<. 
FF+WebRTC 11239.30 CC+WebRTC 2272.54 
<. 





The last pairing comparisons were the differences between the presence 
of WebGL materials (see Table 5). It is hard to decide whether the presences of 
WebGL materials affected the PDU sending and receiving performance, because 
there were two p-values that were less than 0.01. Most comparisons, however, 
were not significantly different from each other. Besides focusing on Table 5, the 
comparisons with less than 0.01 p-values had very good performances on 
sending and receiving DIS messages. Figure 30 shows that both 
FF+WebRTC+WebGL and CF+WebSocket+tWebGL had the capability of 
sending and receiving more than 5,000 DIS packets per second, which was 
much faster than using the Chrome sent to Chrome and the Chrome sent to 
Firefox in the WebRTC framework. 
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Comparison between 


average average 
experimental number of experimental number of 
combination receiving combination receiving 
PDUs PDUs 


FF+WebRTC 11239.30 FF+WebRTIC+WebGL 8562.47 {0.0011 
CF+WebSocket 8212.41 CF+WebSocket+WebGL| 6008.55 0.007 


2300.51 


Table 5. t-test between presences of WebGL components 





B. PROFILING JAVASCRIPT PERFORMANCES 


This thesis used Chrome developer tools and Firefox developer tools to 
profile experimental browsers. The profiling tools were used to record JavaScript 
performances in a period-of-time, and the recording data included percentages of 
time spent and explicit time spent for each function in this period-of-time. For 
example, if a user starts profiling then running the measureDIS function for two 
different lengths of time—one long and the other short—the measureDIS function 
would occupy a small percentage of the long period, but more in the short period. 
Figure 31 shows running the measureDIS function in a long period-of-time, and 
Figure 32 shows running the same function in a short period-of-time. The 
difference was through running the measureDIS function with a shorter time 
(39062.7 ms) in a short period; this function still captured more (19.06%) than the 
one that recorded for a long period-of-time (40247.1 ms with 10.15%). The ‘Self 
column indicates the time to complete the current function that excludes any 
functions it called. The ‘Total’ column shows the time to complete the current 


function and any functions it called (“Profiling JavaScript Performance,” n.d.). 
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Aline | Profiles) Resources Audits 


Tree (Top Down) 


Self 
350339.9 ms 
4575.4 ms 
449.5 ms 
25.6 M5 
LO0S.1 ms 
24 m5 

4.5 m5 


Figure 31. 


Tree (Top Down) 


Self 


153119.2 ms 
12311.2m5 


307.4 m5 | 
29,.1ms 0.01% 
of/4.9 m5 
3.2 M5 
Figure 32. 


Firefox developer tools also have profiling tools. Furthermore, the package 


39094,.9 ms 
S9062./ ms 


Total 
350839.9 ms 
4575.4 ms 
449.8 ms 
40247.1 ms 
40216.1 ms 
2.4m5 
4.55 


Total 


153119.2 ms 
12311.2 m5 


307.4 ms 


Sz M15 


Console NetBeans 


Function 
cole} 
(program) 
(garbage collector) 
¥ (anonymous function) 
 measureDIS 
A dis.EntityStatePdu.encodeToBinaryDIS 
set name 


Running measureDIS function for a long period-of-time. 


éline | Profiles | Resources Audits Console NetBeans 


rc <x 


Function 
(idle) 
(program) 
(garbage collector] 


19.05% | ¥ (anonymous function) 


* measureDIS 
dis DeadReckoningFParameterencodelobinaryvis 


Running measureDIS function for a short period-of-time. 


includes a function to select a certain section to analyze JavaScript 
performances, so the behaviors of sending and receiving DIS PDUs can be 
examined. Looking at the above results of sending and receiving DIS packet 
capabilities, however, the data interchanging rates should refer to the receiving 
capabilities; this means that, although the browser consumes all resources to 
execute the measureDIS function, the efficient outputs would not reflect on the 
receivers. Therefore, it is not worthwhile to check the JavaScript performance of 
purely sending DIS packets. Appendix B-1 is a profiling example of sending DIS 
PDUs in the WebSocket framework. Appendix B-2 selects a section that focused 
on the sending function. Appendix B-3 is the corresponding receiver in this 


example, which evenly consumed approximately 5—7% of the browser resource. 
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After understanding the characteristic of profiling tools, it is difficult to 
analyze a browser's behavior by profiling it with the measureDIS function, 
because the time to invoke the measureDIS function and the time to complete 
sending and receiving DIS messages varies in different networking environments 
and different combinations of browsers. Therefore, this thesis used the profiling 
tools to record the JavaScript performances in the demonstration tank game as a 
practical application, instead of executing the measureDIS function. Based on the 
above results, applying WebGL materials decreased PDU receiving capability in 
both the WebSocket and WebRTC frameworks, but the amount of receiving DIS 


PDUs remained at approximately 1,900 per second. 


Figures 33 and 34 display the recording of the tank game for a period-of- 
time in different networking frameworks. The game setting was that each browser 
had a controllable tank and a projectile that could be fired every two seconds. 
The tank and projectile sent ESPDUs every ten milliseconds, which was different 
from the measureDIS function that sent 200,000 ESPDUs, successively. The fire 
PDU and collision PDU were sent when the corresponding events happened. 
The advantage of profiling the tank game is that it is easy to analyze the sending 
and receiving performances with WebGL elements in different networking 
frameworks, and in client-server versus peer-to-peer configurations. Because the 
profiling tools used the percentage of function executing time and most of the 
functions were invoked periodically (which included graphical rendering and DIS 


heartbeat functions), the different profiling times did not influence the results. 


This tank game sent approximately 200 ESPDUs per second, which is 
below the receiving capabilities in any situation. Figure 33 is a profile of the tank 
game using the WebSocket framework. The profile showed that the renderFunc 
function consumed 32.99% of the recording time to execute this function. The 
renderFunc function is a major function in this tank game, used to render 
graphics and check collisions between 3D objects in the virtual world. It 
contained the tank.update function and many ‘THREE’ functions, which indicated 
the browser spent most of its resources on the WebGL materials. In addition, the 
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websocket.onmessage, heartbeat and munitionHeartbeat functions could be 
found near the bottom of the Function column. The respective percentages for 
these three functions are 0.78%, 0.41%, and 0.33% in the ‘Total’ column. These 
results showed that the exchange of DIS messages did not give browsers a 
heavy workload. Figure 34 is a profile of the tank game using the WebRTC 
framework, and it shows a similar performance with using WebSocket framework. 
The function of _dc.onmessage near the bottom of the Function column is similar 
to the function of websocket.onmessage in WebSocket for listening to incoming 
events. Firefox developer tools profiled similar results, which are shown in 
Appendix C-1 and C-2. C-1, used the WebSocket framework, and C-2 used the 
WebRTC framework. 








| Profiles| Resources Audits Console NetBeans O25 & ie 
Tree (Top Down) ¥T<)> x 
Self Total ¥ Function 
12205.1 ms 12205.1 ms (idle) 
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Ooms 2,0 ms F localloGlobal 
1.0 ms 1.0 ms THREE. Vectors.copy 
1.0m3 10ms 1 THREE. Stené.. addObject 
1.0 ms 1.0m THREE. Vectors 
LO ms 1.0 ms No nyMous TuMEti cin) 
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LO ms 1.0 ms localToGlobal 

Figure 33. Tank game profile using WebSocket framework in Chrome. 


04 


rk Sources Timeline | Profiles) Resources Audits Console NetBeans O4 = *] x 


Tree (lop Down) ¥ & 
Self Total? Function 
fickle} 
Frenderrunc frame?sourceid=,,.-staticto? 551 


¥ Jank.update 
F intersectObject 
» THREE. RaycasterintersectObjects 
F THREE. Ouatenion.multiplyOuatemions 
» THREE. Quaternion.multiply 
THREE. Quaternion.setFromaAxcisangle 
THREE. Vectors.caopy 
F render 
® THREE.ObjectSD.add 
F update 
THREE Quatermion.setFromansAngle 
renderPlugins r= ARRSTMVTe2d,..adgaseSwe 23684 
THREE. Vectors. set iss ARRSTMVTS2d.. VWadgasesweiil46s 
Munition.update 
(program) 
e heartbeat 
F muntionkéeatbeat 





e fr.onload 

r dconmessage 
[garbage collector) 

1 updateEntityMesh frame fsourceid=.,.-staticve2....552 
set name 
THREE. Object30.add 








Figure 34. Tank game profile using WebRTC framework in Chrome. 


C. NETWORK LOADING TIME 


Besides the JavaScript performances, developer tools also provide 
function to record networking behaviors. The recording network information 
included file name, path, status, size, loading time, etc. When a browser visited a 
website initially, it downloaded cached web contents from the web server to the 
local disk. The purpose of caching web contents was to reduce network loading, 
because if the browser visited the same website in a specific period-of-time, the 
browser would verify the status of web contents to decide whether to download 
the web content via the network or access the content from the local disk. For 
example, if a file status showed 200, it meant the file was new to this browser 
and it was downloaded via the network. If a file status showed 304, it meant the 


file had not been modified since the last time it was cached, so the browser 
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would access the file from the local disk. These numbers are HTTP status codes 
that can be looked up on the Internet. In this thesis, the web server's default time 
of caching web content was 604,800 seconds, or one week. All the performance 
tests and tank games were run in a closed networking environment, so the speed 
of loading web contents was very fast. The total loads of the tank game were 
around 6 MB for a single player (see Appendix D). Most of the data consisted of 
graphical models and textures. This thesis used a simple tank model and rough 
terrain model to create a virtual world in browsers. Figure 35 and Figure 36 are 
screenshots of the tank model and the terrain models. The file sizes of these two 
models (hovertank10.js and bterrain.js) were not large; however, the textures for 
these two models were relatively larger than other necessary archives. The 
tank’s texture was 1.1 MB, and the terrain’s texture was 2.5 MB. Other 
JavaScript files (including three.js, peer.js, dis.js, etc.) only made up a small 


percentage of the total web contents. 





Figure 35. screenshot of tank model. 
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Figure 36. Screenshot of terrain model. 


o/ 


THIS PAGE INTENTIONALLY LEFT BLANK 


08 


VI. RESULT DISCUSSIONS 


According to the sending and receiving ability tests, this thesis found that 
different combinations of browsers and different networking frameworks had 
various Capabilities of sending and receiving DIS PDUs. The outcomes showed 
that estimates of the PDU exchange rate should be based on the rate of PDU 
receipt. By analyzing the senders’ memory change, it was discovered that 
sending pages buffered their sending data in their memory, instead of sending 
the data immediately. Although senders queued the sending data in their 
memories, Chrome and Firefox handled their sending events differently, which 
made for different efficiencies. Secondly, analyzing the profiling results showed 
that browsers spent their resources mostly on WebGL components that included 
rendering 3D models and computing intersections between 3D objects. The 
interchange of DIS messages did not account for a big usage of browser 
resources. Thirdly, the web contents that necessarily were downloaded from the 
web server to local browsers did not give any trouble in a local network in the 
experiments. Downloading web contents by remote users might cause latent 
problems such as slowing download or losing data if the necessary files were on 
the Internet or public network with poor connection, which might also affect the 
capability of exchanging DIS messages. Finally, according to the performance 


tests, the scale of web-based simulation using DIS protocol can be proposed. 


A. SENDING AND RECEIVING EFFICIENCY 


According to the performance tests, WebSocket framework had consistent 
receiving rates in both Chrome and Firefox, because the receiving rates were 
based on the outputting rate from the WebSocket gateway server. After taking a 
deeper look at WebSocket gateway server, the server’s receiving rate of DIS 
messages was Close to the receiving rates in recipient browsers, which indicated 
the WebSocket gateway server was efficient in transferring DIS packets. 


Additionally, this server neither use multicast nor broadcast, which were the 


09 


customary ways to distribute DIS packets on the UDP socket. Instead, the server 
delivered DIS PDUs to clients one by one because WebSocket is constructed on 
top of the TCP socket. For example, if there are only two clients connecting to 
the server, client A and client B, when client A is sending DIS messages, the 
server only distributes the receiving data to client B. If there are three or more 
clients, the server has to distribute the receiving data to all connected clients 
one-by-one, except for the sender itself. Therefore, the server distributing data to 


multiple clients decreased the receiving efficiency on recipient clients. 


PeerJS had different performances in different browsers. Implementing 
the WebRTC, PeerJS used peer-to-peer architecture to transfer data, so that the 
sending rate would correspond to the receiving rate. The above results, however, 
indicated that actually the sending rates should refer to the receiving rates. The 
results also showed recipients had better receiving capabilities when using 
Firefox to send data. The method of distributing data in PeerJS was one-by- 
one—which was the same with the WebSocket gateway server—but the 
WebSocket framework used a central server to distribute data. The WebRTC 
framework is set up so that every participant can distribute data to their 
connected peers, and if there are multiple connections to a peer, the receiving 
rates on connected peers will decrease in an inverse ratio (i.e., peer A can send 
2,000 PDUs per second to peer B in a one-on-one situation). If peer A has to 
send to two connected peers, peer B and peer C, the receiving rate in both peer 
B and peer C will be 1,000 PDUs per second. 


By analyzing the receiving rates between browsers, this thesis found 
Firefox had better performances for sending data authentically in both 
frameworks. Figure 3/7 presents comparisons of receiving rates between different 
networks with different combinations of browsers. The x-axis represents the time 
for receiving 10,000 DIS PDUs, and the y-axis represents the first ten 10,000 DIS 
packets. WebSocket and WebRTC were the networking architectures for data 
transferring. When senders started to send 10,000 DIS PDUs for twenty times, 
receivers should have begun to receive data immediately. The figure shows, 
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however, that when data was sent from the Chrome browsers, the recipients took 
longer to receive the first 10,000 PDUs. Another expression of these data in 


linear form is in Appendix E. 


Comparisons of recciving first ten 10,000 DIS PDUs 
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Figure 37. Comparisons of receiving first ten 10,000 DIS PDUs. 


This thesis attempted to send a huge amount of ESPDUs (50,000 
ESPDUs for 50 times), which crashed the Chrome sender after flushing and 
filling all the memory, and the receiver stopped receiving DIS packets. Firefox 
reacted in a different way. Although the Firefox browser indicated that it was not 
responding to the sender, the receiver continued to receive DIS PDUs 
persistently from a slow rate to a fast rate, allowing Firefox to successfully 
receive all 2,500,000 DIS packets after a long period-of-time. Furthermore, the 
transferring data was not lost in the WebSocket framework, and was only rarely 
lost in the WebRTC framework, which might be because the WebSocket is based 
on the TCP socket, while the WebRTC used the SCTP socket to configure data. 


lf there was trouble with sending data in the WebSocket framework, then the 
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WebSocket would close, which meant that the webpage had to be reloaded or a 
WebSocket reconstructed in the browser. If the trouble happened in PeerJS, it 
would complain that the DataConnection object could not send data, but the data 
channel was still on; the browser could continue to send data after dropping all 


the unsent messages. 


B. JAVASCRIPT PERFORMANCE 


Profiling of the tank game showed that most of the browser resources 
were consumed on WebGL components. The sending and receiving functions 
only occupied small portions of the total percentage of browser resources. To 
see the detailed performances of each JavaScript function, Chrome and Firefox 
developer tools provide functions to see the explicit times of each function used. 
This capability could help application developers and designers know how much 


time is spent on each function. 


1. Chrome Developer Tools 


The profiling sample of Figure 33 showed the Chrome browser consumed 
32.99% of the total time to run the renderFunc function, which spent 6455.8 ms 
during the entire period-of-time. This function, however, only spent 28.4 ms on 
itself. The rest of the time was spent on other functions that were invoked by this 
function. Chrome Developer Tools also provides Flame Chart view, which is a 
visual representation of JavaScript performance over time that thus offers a 
different way to view the profiling data. It also provides the running time of each 
function with single invoking, which is different from the aggregated time of 
running a specific function repeatedly. Figure 38 is a sample of invoking one 
renderFunc function in Flame Chart view. The information of the Flame Chart 
view included the name of this function, self time, total time, URL, aggregated 
self time, and aggregated total time. The aggregated total time of the renderFunc 
function was 6.46 s that corresponded to the time 6455.8 ms in Figure 33. Figure 
39 was a portion of the recording profile that included the websocket.onmessage 
and the heartbeat functions. Looking at the details of this flame chart, found that 

62 


the running times of both functions, respectively, were less than 1 ms per 
invoking, and the aggregated total time of the heartbeat function was 81.103 ms, 


which was much shorter than 6.46 s. 
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Figure 38. A Chrome profiling sample of invoking one renderFunc function. 
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Figure 39. A Chrome profiling sample of invoking one websocket.onmessage 
and one heartbeat function. 


2. Firefox Developer Tools 


Firefox developer tools also have the ability to to look up the explicit time 
of each function consumed. Figure 40 is a small sample of profiling the tank 
game with two players in the WebRTC environment. This sample range was from 
2,353 to 2,403 of the complete profile, and the total running time is 49ms. If the 
running time is greater than the self, then there is an arrow at the left of the 
function's name to expand the function tree. In this example, the renderFunc() 
function spent 20 ms in running time, but the self time was zero, which means 
this function was expandable. This example also showed that five renderFunc() 
functions were executed in this 49 ms, which corresponded to the 10ms 
rendering rate. The executing time of each renderFunc() can be found by 
selecting one of these five functions and expending this selected function to see 


the details of self time. 
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Figure 40. A Firefox profiling sample of invoking renderFunc functions. 


After analyzing the JavaScript performances of the tank game, both 
profiling tools showed that even though the heartbeat and the munitionHeartbeat 
functions were invoked at the same rate with the rendering function, the browser 
devoted a large part of its resources to executing WebGL components rather 
than exchanging DIS PDUs. Therefore, the native capabilities of both WebSocket 
and WebRITC in browsers are competent enough to support web-based DIS 


simulations. 


C. LOAD OF NECESSARY ARCHIVES 


Loading page content from the server was no problem in_ this 
demonstration tank game because of the following reasons. First, all the tests 
were executed in a local networking environment. Second, the distributed files 
were only around 6M B for each client, and there were not many clients. Third, 
the client computers had very powerful CPUs and graphic cards. If someone 
wants to improve the sophistication of the tank game, however, then the archival 
size of models and textures must be increased. The sophistication of the model 


also increases the burden of computational power in clients. There are many 
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existing 3D models in various formats on the Internet, and it is easy to find a 
sophisticated model over 10 MB. Although web browser has capability to cache 
files from web server, it still has to load every necessary archive at the first time. 
If there are several large-size 3D models that have to be downloaded as web 
contents, the data distribution via public network would become a fundamental 
issue for building up web-based simulations. There are some popular techniques 
for reducing the impact of loading large data into web page such as minify 
JavaScript, apply Content Delivery Network, remove duplicate scripts (Souders, 
2007). 


D. GAME SCALABILITY 


According to the results from performance tests, receiving rates were the 
major references for interchanging DIS PDUs in the network. Hence, the 
receiving rate can be used to scale the size of web-based multi-player games or 
simulations. For example, the lowest receiving rate in the experiments was 
around 1,900 PDUs per second, which was achieved when sending PDUs by 
Chrome browser in a peer-to-peer connection. Based on this result, a suggested 


number of players can be found by using equation (1). 


Three variables that had to be considered: number of entity that sent 
ESPDU repeatedly, heartbeat rate, and number of clients; multiplying these three 
variables should result in a number less than 1,900. This tank game had two 
entities: tank entity and tank’s ammunition entity; both entities sent ESPDU 
frequently. Each entity had its own heartbeat rate. Summing up the heartbeat 
rates multiplied by the corresponding entity would give the total amount of 
sending ESPDUs routinely, which excluded sending collision PDU and fire PDU. 
The game setting of the heartbeat frequencies for both tank and _ tank’s 
ammunition was 10ms, which was equal to sending 100 ESPDUs per second. 
Therefore, the total amount of sending ESPDUs was around 200 per second. 
The last variable was the number of clients, because the sending technique was 


one-by-one on peer-to-peer connections and WebSocket gateway server. The 


66 


multiplier of the client number should be the total number of clients, minus the 
one that was the sending client itself. Back to the question, the suggested 
maximum number of players to play the tank game was 10 (the calculating result 
was 10.5 with the equation (1*°100+1*100)*(TC-1) = 1900). 


Se “aR |(1C~1) < 2000 (1) 


j=l 
where, 


nm = total number of entities. 

£; = each entity 

HA, = heartbeat rate for the corresponding entity. 

TE = total number of client 

Ten players were not the maximum number playing the tank game. 
Different networking frameworks with different browsers had different capabilities 
of exchanging DIS packets. In addition, there are other ways to adjust the game 
Capacity, such as changing the number of entities that frequently sent ESPDUs, 
and adjusting the heartbeat rate. One example was modifying the JavaScript 
program so that the tank’s ammunition sent ESPDUs only when a tank fired, 
instead of the projectile sending ESPDUs periodically; the projectile would only 
send ESPDUs when its velocity was not zero. Another way was to adjust 
heartbeat rate on each entity. The rate of heartbeat affected game animation in 
participant's browsers because browsers used receiving ESPDUs to update 
entity positions and states. At 100 ESPDUs per second, the effective rendering 
rate is 100 fps in the remote participants, and it is not necessary to set an 
identical rate on both heartbeat and canvas rendering. In modern video games, 
30 fps is qualified enough to be a commercial game, if this tank game lowered its 
heartbeat rates, the capacity of the number of players and/or the number of 
entities must be increased. Appendix F shows screenshots of multiplayers in the 


example tank game. 
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Vil. CONCLUSION AND FUTURE WORKS 


A. CONCLUSION 


The objectives of this thesis were to discuss and prove the feasibility of 
developing DIS web-based simulations using JavaScript. This thesis 
incorporated many web technologies and DIS protocol to outline infrastructures 
that supported web-based simulation. The major web technologies included 
JavaScript, WebSocket, WebRTC, and WebGL; there were many existing APIs 
that wrapped WebRTC and WebGL to help developers create web applications. 
This thesis suggested two different networking architectures, client-server and 
peer-to-peer, for interchanging DIS messages; and tested the capability of 
sending and receiving DIS PDUs between browsers. Furthermore, this thesis 
also integrated the above technologies to develop a browser-based tank game 
as a test application, and analyzed the performance of the tank game in different 
networking frameworks. At the same time, taking the advantage of cross-platform 
in browsers, both performance tests and the tank game can be executed and 
analyzed in Chrome and Firefox browsers, Internet Explorer and Safari did not 
support WebRTC yet. Other benefits of using web-based simulation included 


model reusing, collaboration, deployment, accessibility, and versioning control. 


According to the performance tests and analysis of the demonstrating tank 
game, this thesis found that the modern web technologies are capable enough to 
construct web-based simulations. The performance tests included the capability 
of simply sending and receiving DIS PDUs in different networking frameworks; 
comparing the performance between the applying of WebGL materials; and 
cross-browser performances between Chrome and Firefox. The analysis of the 
tank game contained the resource consumption of rendering WebGL materials 
and interchanging DIS messages; and the page loads of necessary files from 
web server. The followings are the conclusions for the performance tests and the 


game analyses. 
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The performance tests showed that the speed of executing the sending 
ESPDUs function was faster than both WebSocket and WebRTC sent DIS 
messages. In fact, the measurements of sending rates were much higher than 
the receiving rates, meaning it was better to use receiving throughput as a 
reference to scale the size of web-based simulation. Both Chrome and Firefox 
have similar performances of sending and receiving DIS PDUs using the 
WebSocket framework. The performances of the WebRTC framework, however, 
favored Firefox. While using Firefox to send DIS packets via the WebRTC 
framework, both Chrome and Firefox had a better performance than any 
experiments with the WebSocket framework. While using Chrome to send the 
PDUs via the WebRTC, both Chrome and Firefox had worse performances than 
all the experiments with the WebSocket framework. Therefore, the Firefox and 
WebRTC combination is currently better than other combinations provided 


WebRTC is implemented using PeerJS. 


This thesis used the worst-case performance of receiving rate (around 
1,900 PDUs per second) as a guidance for scaling the tank game. The tank 
game had two entities that repeatedly sent 200 ESPDUs per second. The 
calculating result showed that this tank game was suitable for up to ten players. 
In addition, there were variables that could be adjusted to enlarge the capacity of 
the tank game, such as the heartbeat rate or the amount of entity that periodically 
sent ESPDU. The capacity of ten players was good enough to create an online 
game. For example, ten players can be divided into five-versus-five players. 
Famous examples of five-versus-five games include League of Legends and 
Defense of the Ancients (DotA) in Warcraft III; however, they are not web-based 


games. 


This thesis used Chrome and Firefox developer tools to profile the tank 
game and recode the time of loading web contents. Profiling tools contained 
percentages of time that each function used, and explicit times of each function 
spent. The profiling results showed most of the browser resources were spent on 
WebGL components, and the function for exchanging DIS packets only used a 
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small portion of the browser resources (see Figure 33, Figure 34, Appendix C-1, 
and Appendix C-2). The times of loading web contents showed browsers 
received all necessary web contents quickly in a closed network (see Appendix 
D). 


Based on the above results, the DIS protocol could be applied in web- 
based applications. Both WebSocket and WebRTC frameworks were capable of 
supporting a ten-player first-person-shooter game in a browser, and the size of 
the game was expandable by adjusting the variables. WebGL created 3D 
graphics shows in web browsers without any plugins, and the performance of 
WebGL was dependent on the power of computers and the degree of model 
complexity, which was a trade-off among budget, performance, and the quality of 
3D models. Methods of using the DIS protocol and the game styles are varied. 
This thesis showed that web-based DIS simulation is workable, and simulation 
designers could refer to the basic capability of exchanging DIS messages to 


develop web-based simulation for different purposes. 


B. FUTURE WORKS 


This thesis sought quick ways of constructing networking environments to 
interchange DIS between different browsers, so simulation developers could 
focus on the functions and scenarios for different purposes. This thesis also 
focused on developing an example game as a practical application to verify the 
feasibility of web-based simulation. There were some experiments and 
improvements that were not performed in this thesis, such as: performance 
testing of mobile devices; improvement of the WebRTC sending capability in 
Chrome browsers; benchmark testing of the WebSocket and the WebRTC in 
different browsers; discussions of disadvantages of web-based simulations; and 


comparisons between web-based DIS simulations and traditional DIS simulations. 


1. Performance Tests and Web Applications on Mobile Devices 


The development of mobile devices has flourished in the past few years, 


and most of the mobile devices have installed web browsers such as iOS Safari, 
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Opera Mini, Android Browser, and Chrome for Android. One of the advantages of 
web applications is cross-platform, which indicates mobile devices can execute 
web applications in their compatible web browsers. Currently, almost every 
browser supports WebSocket, except Opera Mini; however, only Chrome for 
Android supports the WebRTC. This thesis did not measure the performance of 
interchanging DIS PDUs between browsers in mobile devices. This result would 
be a consideration for developing web applications, because the computational 
performance on mobile devices is typically slower than personal computers or 
laptop computers. Other considerations include WebGL components and input 
mechanisms. WebGL is one of the major elements that uses a lot of browser 
resources. So far only Chrome for Android supports WebGL, but the next version 
of iOS Safari will begin supporting WebGL(Deveria, n.d.-a). In addition, mobile 
devices usually do not attach to a keyboard or mouse, and the main input device 
for mobile device is a touch screen. Therefore, development of web applications 
for mobile devices has to take into consideration input mechanisms using 


graphical user interfaces (GUI) for users. 


2. Improvement of WebRTC Sending Capability in Chrome 
Browser and Benchmark Test 


According to the results in Chapter V, Performance Tests, the lowest 
receiving rates were from Chrome sent to Chrome and Chrome sent to Firefox. 
This thesis used PeerJS that wrapped WebRTC to create data channels between 
browsers. PeerJS is an easy and convenient API for developers to create web 
applications that apply WebRTC functions in a browser. However, because 
PeerJS is a wrapped API, it is difficult to modify or change the JavaScript code 
inside the API. Additionally, there is no benchmark application for testing 
WebRTC performance between Chrome and Firefox. Comparing with the 
receiving capability that sending from Firefox browser (Figure 29), it seems like 
Chrome should have space for improvement in the performance of the WebRTC 
framework. Therefore, further studies directed at WebRTC technology are 


required to improve the sending performance of the Chrome browser. 
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3. Disadvantages of Web-based Simulation 


This thesis discussed the advantages of web applications, along with the 
establishment of infrastructures that exchange DIS messages, and the 
development of the tank game. Some disadvantages of web-based simulations 
were not studied or discussed in this thesis, such as security vulnerability, GUI 
limitation, and latency. In addition, further study and discussion should contain 


comparisons between web-based DIS simulation and traditional DIS simulation. 


4. Feasibility of Other Web-based DIS Applications 


This thesis only developed a first-person-shooter tank game as an 
example of a DIS simulation in a browser. However, applications that use DIS 
protocols are varied. Further research is needed to discover which web-based 
domains can be applied to DIS simulations. For example, the WebSocket 
gateway server can receive native DIS from a UDP socket, so browsers can 
receive DIS packets from other simulation systems such as VBS2. Is it possible 
to create a battlefield viewer by receiving DIS messages in browsers, or to create 
a simplified interactive game interface in browsers? On the other hand, WebRTC 
emphasizes real-time communication between browsers, and is designed for 
audio and video communication. Is it possible to incorporate audio and video in 
web-based DIS simulations? What is the benefit of incorporating audio and video 
in web-based simulations, and does it affect the performance of sending and 
receiving DIS PDUs? 


2. Performance Tests in Public Networking Environments 


All the experiments and performance tests in this thesis were done in a 
closed-networking environment. Both WebSocket and WebRTC were competent 
enough to support web-based DIS simulations; however, a public networking 
environment is much more complex. Both WebSocket gateway servers and 
WebRTC peers used one-by-one mechanisms to distribute DIS packets, but the 
bottom layers were different. The WebSocket was based on a TCP socket, and 


the WebRTC used a UDP socket. This thesis did not examine performances on a 
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public network or Internet environments. Additional experiments should be done 
to compare the performance between the WebSocket and the WebRTC on a 


public network. 
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APPENDIX A. TABLE OF ENTITY STATE PDU FIELDS 


Appendix A shows the fields of entity state PDU, and DIS simulation uses 


ESPDU to communicate information about an entity’s state. 


ras ; Entity State PDU fields 


Protocol Version—8-bit enumeration 
Exercise [D—8-bit unsigned integer 
PDU Tyoe—$-bit enumeration = 1 
oe Protwwcel Fanuly—-bit enumeranon = | 
PDU Header | 
Timestamp—32-bit unsigned mte per 


Length—16-bit unsigned mteger 
PDU Status—$-bit recond 





Padding—S bits unused 
Site Number—16-bit unsimned mteger 


Apphcaton Number—16-bit unsigned integer 


Enury Number—16-bit ussigned imeger 


Country—16-bit enumeration 
Ectity Type Category—8-bit enumeration 

Subcategory—8-bit enumeration 

Specific—s-bit enumeration 

Extra—$-bit enumeration 

Entry Kind—$-bit enumeration 


Doman—é -bit enumerabon 


Ablermate Ennty Type Categor;—8-bit enumeration 
Subcategory—8-bit enumeration 
Specific—S8-bit enumeration | 
com penem—I32-bit flozung pot | 


Ectity Linear Velocity y-compenent—32-bit floating pomt 





z-compcnent— 32-bit floating pount 
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Psi (w}—32-bit floating point 
Theta (9)—32-bit floating point 
Phi (6}—32-bit floating point 

| 32-bit record 


Dead Reckomng Algorithm—3-bit enumeration 


ibe Faraweiers—1 20 tnis 


Fatty Lanes Acceleratian— 4% 49 shat flaating pont 


Entity Angular Velocity—3 » 32-bit floating point 


Ll. §-bit unsigned mtegers 


Record Type—2-ba enumeration 
Vanable Parameter record #1 







































































Recend-Speewie felds—120 tas 





Recon Type—8-bu enumetanon 


Vanable Parameter record @.V 
Record. Specific fielde—120 bite 


Total Enuty State PDU size = 1192 + 128.4 bits 


where 





| MN as the oumber of Variable Parameter records 








Table 6. __ Fields of entity state PDU. 
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APPENDIX B. FIREFOX DEVELOPER TOOLS 
PERFORMANCE PROFILE RESULTS 


A. APPENDIX B-1. FIREFOX PROFILING OF SENDING ESPDUS 


Appendix B-1 shows a result of using Firefox developer tools to profile the 


sending behavior in the WebSocket framework for a short period-of-time. 
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Figure 41. Firefox profiling of sending ESPDU in the WebSocket framework. 
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B. APPENDIX B-2. SENDING SECTION IN APPENDIX B-1 


Appendix B-2 shows the sending section in Appendix B1. 
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Figure 42. sending section in Appendix B1. 
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C. APPENDIX B-3. FIREFOX PROFILING OF RECEIVING ESPDUS 


Appendix B-3 shows a result of using Firefox developer tools to profile the 


receiving behavior in the WebSocket framework for a short period-of-time. 
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Figure 43. Firefox profiling of receiving ESPDU in the WebSocket framework. 
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APPENDIX C. TANK GAME RESULTS 


A. APPENDIX C-1. FIREFOX PROFILING IN THE WEBSOCKET 
FRAMEWORK 


Appendix C-1 shows a result of profiling the tank game using Firefox 
developer tools in the WebSocket framework. 
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Figure 44. Firefox profiling of the tank game in the WebSocket framework. 
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B. APPENDIX C-2. FIREFOX PROFILING IN THE WEBRTC FRAMEWORK 


Appendix C-2 shows a result of profiling the tank game using Firefox 
developer tools in the WebRTC framework. 
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Figure 45. Firefox profiling of the tank game in the WebRTC framework. 
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APPENDIX D. NETWORK LOADING TIME 
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Appendix D is an example of recording the time of loading web contents. 
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APPENDIX E. COMPARISONS OF RECEIVING FIRST TEN 10,000 
DIS PDUS IN THE LINEAR FORM 


Appendix E is the comparisons of receiving first ten 10,000 DIS PDUs in 
the linear form. It shows that the times of receiving first one 10,000 DIS PDUs 


were slower when the senders were Chrome. 
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Figure 47. The comparisons of receiving first ten 10,000 DIS PDUs 
in the linear form. 
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APPENDIX F. SCREENSHOTS OF MULTIPLAYERS 
IN THE TANK GAME 


Appendix F shows that it is possible to create a web-based DIS simulation 


for many users. 








Figure 49. Screenshots of multiplayers in the tank game II. 
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Figure 50. Screenshots of multiplayers in the tank game III. 
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Figure 51. Screenshots of multiplayers in the tank game IV. 
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